home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Dec 90 / MacApp.Tech$ 12⁄14⁄90 / 2504-Re MacApp vs. AppMak-Dec90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.8 KB  |  79 lines  |  [TEXT/GEOL]

  1. Item    3813640                         14-Dec-90        00:35PST
  2.  
  3. From:   MUYSVASOVIC                     ACE - Jean-Denis Muys-Vasovic
  4.  
  5. To:     INTELITOOL                      Intelitool, Alan F Holmquist,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. ------------------------------------------------------------------------------
  10.  
  11. Sub:    Re: MacApp vs. AppMaker
  12.  
  13. Chuck,
  14.  
  15. In fact, you cannot compare, MPW C/Pascal, MacApp, and Appmaker against one
  16. another. They are quite different tools, which have all a place in the
  17. development process. Let me elaborate a bit.
  18.  
  19. To do any development, you'll need at least the three following components:
  20.  
  21. 1- Development tools, including a development environment (eg MPW, Think), and
  22. utilities which might be more or less necessary (eg ResEdit, AppMaker,
  23. ViewEdit, MacBrows…).
  24.  
  25. 2- A language (eg C++, Object Pascal, Lisp, COBOL).
  26.  
  27. 3- A code library (eg the Mac Toolbox, MacApp…).
  28.  
  29. MacApp was written by Apple to work with MPW. For another environment to be
  30. compatible with MacApp, it must satisfies either one of two conditions: a-
  31. source level compatibility. Since MacApp was written in Object Pascal, it must
  32. then support Object Pascal. Example: Think pascal. or b- object level
  33. compatibility. Here that means it must be able to import MPW .o files, and also
  34. respect the Pascal calling conventions. Weak example: p1 Modula II.
  35. Specifically, Think C doesn't satisfy as of today either of the two conditions.
  36. Therefore the answer to your question is no. It now belongs to Symantec to take
  37. action. This is a more general problem with Think environment: they are
  38. mono-language. You should be able to write an application party in Think
  39. Pascal, partly in Think C.
  40.  
  41. AppMaker could be classified in the broad category (who said class?) of CASE
  42. tools. It is supposed to solve a general problem: I want to draw my user
  43. interface on the screen, and not the code to generate it. Both MacApp and
  44. AppMaker have an answer to that problem, but they are very different in nature.
  45.  
  46. AppMaker chose to generate source code. The advantage of this approach is
  47. generality. You can easily tie a menu item with a dialog for example. You can
  48. generate the glue code with the "real" stuff. The disadvantage is lack of
  49. maintainability and localizability: quite often, you can't redesign your user
  50. interface, even the slightest detail, as soon as you've started adding your
  51. code to the generated code. I learned that the latest version of Prototyper,
  52. the competitor of AppMaker, has solved this problem. I haven't seen it yet, but
  53. I suspect there are some unpleasant constraint to achieve that. Any report
  54. appreciated.
  55.  
  56. MacApp chose the resource approach. The interface is specified in resources (eg
  57. 'cmnu' and 'view'). The resources are then read in at run time by the code
  58. library, and the specification followed. The disadvantage of this is that you
  59. lose completeness: you must write the glue code to call on the library and to
  60. link the user interface elements together. Also, the supporting code is more
  61. complex, since it belongs to the library, instead of the utility (AppMaker).
  62. One advantage of that is localizability, because you don't have to recompile
  63. your application to change the specification. Another is maintainability,
  64. because the supporting code is not part of your source code. If a bug is
  65. discovered, or if a feature is enhanced, you just have to relink with the new
  66. version of the library (well, to a certain extent).
  67.  
  68. A good try would be to combine both approches, eg use AppMaker to generate the
  69. glue code which will call MacApp code. This possibility will soon be offered by
  70. AppMaker. See also MacApp drafter on ETO.
  71.  
  72. In the current state, AppMaker is not compatible with MacApp. This disqualifies
  73. AppMaker for most serious development.
  74.  
  75. I hope I clarified things a bit.
  76.  
  77. Jean-Denis
  78.  
  79.